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Testbed  omgeving  voor  gedistribueerde 
waarneming 


Het  optreden  van  Defensie  zal  in  de  toekomst  in  toenemende  mate  een 
netwerk-centrisch  karakter  hebben.  Dit  behelst  ondermeer  de  inzet  van 
kleinere  modulaire  eenheden  waarbij  de  data  van  verschillende  devices, 
deels  geplaatst  op  onbemande  platformen,  moet  worden  samengevoegd 
tot  bruikbare  informatie.  Dit  rapport  beschrijft  een  Testbed  omgeving  als 
platform  voor  zulke  samenwerkende  devices. 


Probleemstelling 

Dit  projectrapport  is  onderdeel  van  het 
programma  V219  en  beschrijft  een  Testbed- 
omgeving  waarbinnen  sensorcombinaties 
(eventueel  ondersteund  door  andersoortige 
randapparatuur)  kunnen  worden  getest  en 
getivalueerd.  Data  van  verschillende 
sensoren,  deels  geplaatst  op  onbemande 
platformen,  moet  kunnen  worden 
samengevoegd  tot  informatie  die  door 
operationele  teams  gebruikt  kan  worden. 

Bij  de  specificatie  van  dergelijke  complexe 
systemen  is  een  vroegtijdige  afweging  van 
consequenties  aangaande  de  implementatie 
van  kritische  componenten,  de 
realiseerbaarheid  en  de  daarmee  gepaard 
gaande  kosten  van  wezenlijk  belang. 


Beschrijving  van  de 
werkzaamheden 

In  het  eerste  deel  van  dit  document  komen 
de  verschillende  concepten  waarin 
gedistribueerde  sensoren  een  rol  kunnen 
spelen  alsmede  de  protocollen  van  het 
Testbed  aan  de  orde.  Er  wordt  beschreven 
hoe  ieder  apparaat  als  een  ‘Networked 
Intelligent  Device’  kan  worden  gezien, 
hetgeen  integratie  en  samenwerking  tussen 
devices  in  een  netwerk  mogelijk  maakt. 

Het  tweede  deel  beschrijft  een 
demonstratie-systeem  van  een  complete 
compound  security  applicatie  met  het 
Testbed. 

Hierbij  komen  geselecteerde  subsystemen 


aan  bod  en  hun  samenhang  in  het  complete 
demonstratie-systeem. 

Resultaten  en  conclusies 

Er  is  aangetoond  dat  data  van  verschillende 
sensoren  kunnen  worden  samengevoegd  tot 
bruikbare  informatie.  Als  demonstratie- 
systeem  is  gekozen  voor  het  detecteren  en 
volgen  van  bewegende  mensen,  waarbij 
metingen  van  verschillende  sensoren  in  het 
volgproces  worden  gecombineerd. 

Tijdens  dit  project  is  gebleken,  dat 
informatie-uitwisseling  tussen  verschillende 
systemen  in  een  genetwerkte  omgeving 
geenszins  triviaal  is.  De  uitdaging  zal 
blijven  zitten  in  het  definieren  van  de  juiste 
interfaces  die  aan  de  ene  kant  generiek  en 
flexibel  zijn  en  aan  de  andere  kant  specifiek 
en  applicatie-afhankelijk  zijn. 

Toepasbaarheid 

Het  Testbed  is  gereed  voor  gebruik. 

De  omgeving  kan  gebruikt  worden  voor  het 
testen  en  evalueren  van  multi-device 
systemen,  bijvoorbeeld  in  het  kader  van 
NEC. 
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1  Inleiding 


Hct  optrcdcn  van  Defensie  zal  in  dc  toekomst  in  tocnemendc  mate  een  netwerk- 
centrisch  karakter  hehhen.  Ontwikkclingen  op  dit  gehied  behelsen  de  inzet  van  kleinere 
modulaire  eenheden  waarbij  de  data  van  verschillende  sensoren,  deels  geplaatst  op 
onbemande  platformcn,  moet  worden  samengevoegd  tot  bruikbare  informatie. 

Dit  vereist  compacte,  in  real-time  werkende  systemen  met  een  hier  op  toegesneden 
communicatienetwerk. 

Voor  commando-posten  bijvoorbeeld  wordt  het  steeds  moeilijker  om  de  juiste 
beslissingen  te  nemen  zonder  adequate  ondersteuning  van  technische  hulpmiddelen. 

Een  gedistribueerd  waarnemingsysteem  is  een  voorbeeld  van  een  technische 
ondersteuning.  Zo’n  systeem  bestaat  uit  een  aantal  sensoren,  mogelijk  ook  actuatoren 
waaronder  displays,  die  via  een  data-communicatienetwerk  gekoppeld  zijn. 

Zulke  systemen  hebben  tot  doel  de  ‘situation  awareness’  van  de  commando-post  te 
verbelercn.  Dit  is  onder  andere  van  belang  voor  beveiliging  (schepen,  compounds), 
expeditionair  optreden  en  evaluatie  van  concepten  voor  Networked  Enabled 
Capabilities  (NEC)  en  autonome  systemen. 

Ofschoon  hct  concept  van  gedistribueerde  waarneming  niet  nicuw  is,  zorgen 
ontwikkclingen  van  de  afgelopcn  jaren  op  technologisch  gebied  ervoor  dat  nu  practisch 
werkbare  systemen  gecreeerd  kunnen  worden.  De  momenteel  grootste  problemen  zijn 
standaardisatie  van  de  interfaces  (zowel  op  hardware  als  op  software  niveau)  en  de 
stabiliteit  van  het  complete  systeem.  Typische  voorbeelden  van  gedistribueerde 
waarnemingsystemen  zijn  radars  of  electro-optische  sensoren  voor  detectie  en  volgen 
van  objecten  (‘search,  track  and  trace’).  Andere  voorbeelden  waarbij  gedistribueerde 
waarneming  een  bclangrijke  rol  kan  spelen  is  bij  de  detectie  en  localisatie  van  snipers  of 
mortieren. 

Om  informatie  van  sensoren  te  combineren  wordt  vaak  gebruik  gemaakt  van  een 
centraal  systeem,  dat  de  signalen  van  de  sensoren  inleest,  verwerkt  en  combineert. 
Doorgaans  is  hct  veel  en  inefficient  werk  om  dit  voor  elkaar  te  krijgen.  Dit  komt  omdat 
de  interfaces  niet  gestandaardiseerd  zijn  noch  de  data  die  door  de  sensoren  geleverd 
wordt.  Bovendien  zal  er,  in  het  geval  dat  er  veel  sensoren  gebruikt  worden,  een 
‘overload’  ontstaan  bij  de  centrale  van  te  verwerken  data.  Een  gedistribueerd 
waarnemingsysteem  daarentegen  bestaat  uit  ‘intelligente’  sensoren  die  zelf  een  deel  van 
de  informatieverwerking  verzorgen  voordat  ze  hun  resultaten  naar  de  commando  post  of 
naar  andere  sensoren  versturen  voor  evaluatie.  Dit  heeft  het  grote  voordeel  dat  de 
signaalverwerking  verspreid  wordt  over  het  netwerk  hetgeen  gunstig  is  voor 
bandbreedte-behoefte  omdat  de  ge-extraheerde  informatie-berichten  doorgaans  kleiner 
zijn  dan  de  rauwe  sensordata.  Bovendien  zal  er  geen  overload  optreden  bij  de  centrale. 

Dit  projectrapport  is  onderdeel  van  het  programma  V219  en  beschrijft  een  Testbed- 
omgeving  waarbinnen  sensorcombinaties  (eventueel  ondersteund  door  andersoortige 
randapparatuur)  kunnen  worden  getest  en  geevalueerd.  Data  van  verschillende  sensoren, 
deels  geplaatst  op  onbemande  platformen,  moet  kunnen  worden  samengevoegd  tot 
informatie  die  door  operationele  teams  gebruikt  kan  worden.  Bij  de  specificatie  van 
dergeli  jke  complexe  systemen  is  een  vroegti  jdige  afweging  van  consequenties 
aangaande  de  implementatie  van  kritische  componenten,  de  realiseerbaarheid  en  de 
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daarmce  gepaard  gaandc  kosten  van  wezenlijk  helang.  Een  voorstudie  die  tot  de 
spccificaties  van  hct  Testbed  hebben  geleid  is  besehreven  in  1 1  ]. 

Bovendien  bevordert  een  Testbed  omgeving,  die  in  meerdere  projecten  en  programma’s 
gebruikt  kan  worden,  het  hergebruik  van  kennis  cn  tcchnologie-ontwikkelingen  en 
draagt  bij  tot  een  betere  samenhang  lussen  de  verschillende  programma’s.  Dit  maakt  het 
mogelijk  om  technologieen  en  ontwikkelingen  uit  te  wisselen  tussen  versehillende 
applicatiedomeinen  (bijvoorbeeld  van  de  Koninklijke  Marine  en  Koninklijke 
Landmaeht).  Dit  alles  resulteert  in  een  verbrede  kennisbasis  met  betrekking  tot 
gedistribueerde  waarncming. 

De  doelstcllingen  van  het  Testbed  zijn: 

1  Efficienter  onderzoek  en  ontwikkeling  van  concepten  en  technologieen  door 
hergebruik  van  infrastructuur  (het  Testbed). 

2  Demonstratie  van  de  relevantie  van  nieuwe  techniekcn  en  applicaties  ten  behoeve 
van  defensie. 

3  Evaluatie  van  concepten  en  technieken  als  onderdeel  van  een  hybride  (simulatie- 
demonstratie)  omgeving. 

4  Kennisopbouw  met  betrekking  tot  gedistribueerde  waarnemingssystemen  ten 
behoeve  van  consultancy  aan  de  Krijgsmacht  en  realistische  simulatie  van 
dergelijke  systemen. 


Dit  document  is  onderverdeeld  in  twee  delen,  die  de  werkzaamheden  beschrijven  van 
twee  samenhangende  projecten,  namelijk  ‘Protocollen  Testbedomgeving’  en 
‘Demonstratie  Testbedomgeving’.  Het  eerste  deel  beschrijft  het  Testbed  en  de  gebruikte 
protocollen,  in  hoofdstuk  2  en  3.  Als  basis  voor  de  gemaakte  keuzes  gelden  de 
aanbcvelingen  uit  het  voorafgaande  project  ‘Definitie  Testbed  Omgeving’  [  1  ]. 

Het  tweede  deel  beschrijft  een  demonstratie-systeem  van  een  complete  applicatie  met 
het  Testbed.  Dit  werk  is  het  resultaat  van  project  ‘Demonstratie  Testbedomgeving’. 
Hierin  komen  een  aantal  geselecteerde  sensoren  aan  bod  en  hun  samenhang  in  een 
complcet  systeem  voor  gedistribueerde  waarneming  wordt  gedemonstreerd. 

Tot  slot  volgen  de  conclusies  in  het  laatste  hoofdstuk. 
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2  Toepassingen 


Hct  primaire  duel  van  de  Testbed  omgeving  is  het  testen  en  cvalueren  van 
gedistribueerde  waarnemingsystemen.  In  dit  hoofdstuk  wordt  ingegaan  op  een  aantal 
mogelijke  toepassingen  van  dit  testbed. 

2.1  Introductie 

Dc  Nederlandse  Krijgsmacht  richt  zijn  activiteiten  dikwijls  op  vredesoperatics. 

Tijdens  deze  operaties  heeft  de  bescherming  van  eigen  personeel  en  materieel  een  hoge 
prioriteit.  In  dit  verband  is  cr  behoefte  aan  systemen  die  een  grote  flexibiliteit  bezitten 
qua  reaetie  op  de  lokaal  heersende  dreiging  en  die  bovendien  de  minimale  bezetting  van 
personeel  vereisen.  De  motivatie  voor  deze  behoefte  is  hieronder  samengevat  in  een 
aantal  huidige  knclpunten  met  betrekking  tot  het  gebruik  van  technische 
ondersteuningsystemen: 

-  Hoge  personele  inzet. 

-  Risico’s  voor  het  personeel. 

-  Beperkte  dekkingsgraad. 

-  Extreme  omgevingsfactoren  zoals  hitte,  kou,  mist,  zandstormen,  ete. 

-  Niet  altijd  wenselijke  militaire  ziehtbaarheid  terwijl  de  omgeving  loch  geobserveerd 
moet  worden. 

-  Omgang  met  onverwachte  incidenten. 

-  Onbckendheid  met  de  situatie. 

Het  gebruik  van  een  gedistribueerd  sensorsysteem  kan  tegemoet  komen  aan  deze 
knclpunten.  Door  gebruik  te  maken  van  autonome  sensoren  is  minder  personeel  nodig 
voor  bewaking  en  observatie.  De  observatie  vindt  plaats  op  afstand,  dit  reduceert  het 
risico  voor  het  personeel.  Door  de  inzet  van  sensoren  in  combinatie  met  het  personeel 
worden  meer  observatiepunten  verkregen  en  wordt  de  dekkingsgraad  groter. 

Met  andere  woorden  met  dezelfdc  hoeveelheid  personeel  kan  een  groter  gebied  worden 
gecontroleerd.  Daarnaast  zi  jn  sensoren  altijd  waakzaam  en  kunnen  relatief  risicoloos 
fungeren  als  vooruitgeschoven  observatieposten  waardoor  een  vroegtijdige  alarmering 
wordt  verkregen  en  het  gevaar  voor  overmacht  wordt  gereduceerd.  Daarnaast  geeft  de 
inzet  van  sensoren  een  completer  beeld  van  de  momentane  situatie  door  de  hoeveelheid 
observatiepunten.  Door  het  gebruik  van  digitale  kaarten  worden  de  actuele  troepen-, 
burger-  en  voertuigverplaatsingen  real-time  in  kaart  gebracht.  Dergelijke  sensoren 
kunnen  bijvoorbeeld  voor  een  snelle  inzet  worden  uitgestrooid  waarna  de  sensoren 
autonoom  bepalen  welke  sensor  welke  informatie  verzamelt  en  van  welk  gebied. 

Dit  met  als  doel  het  optimaliseren  van  het  energieverbruik  (en  dus  de  levensduur)  bij 
een  zo  goed  mogelijke  dekkingsgraad.  De  dekkingsgraad  kan  bijvoorbeeld  worden 
bepaald  door  het  uitwisselen  van  de  GPS  posities  tussen  de  sensoren. 

In  het  veld  kunnen  een  groot  aantal  verschillende  sensoren  worden  ingezet. 

Hierbij  kan  gedacht  worden  aan: 

-  Lichtstraal  onderbrekers. 

-  Struikeldraad. 

-  Bewegingsdetectie  met  radar  of  infrarood. 

-  Snelheidsmcting  met  radar. 

-  Objectdetectie  en  classificatie  met  radar  of  infrarood. 

-  Seismische  sensoren  (bijvoorbeeld  voetstapdetectors). 
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-  Magnetische  lussen. 

-  Akoestische  sensoren. 

-  Strijdgasdetectoren. 

-  Meteorologische  stations. 

In  de  volgcndc  paragrafen  worden  ecn  aantal  typische  applicaties  beschreven  waarin 
gcdistribuccrdc  intclligcntie  een  bclangrijke  rol  kan  spclcn. 

2.2  Compound  security 

Wanneer  een  militaire  eenheid  crgens  neerstrijkt  moct  het  kampcmcnt  (compound) 
beschermd  worden  tegen  indringers.  Wenselijk  is  hct  dat  het  terrcin  om  de  compound 
zo  snel  mogelijk  na  vestiging  bewaakt  wordt.  Verschillende  methoden  zijn  denkbaar 
hiervoor.  Momenteel  worden  hiervoor  bijvoorbeeld  gevechtsveld-radar,  warmtebeeld- 
cameras  of  tripwires  gebruikt.  Deze  systemen  staan  doorgaans  op  zichzelf,  dat  wil 
zeggen,  ze  zijn  niet  op  een  data-netwerk  aangesloten.  Momenteel  is  er  echter  behoefte 
aan  systemen  die  wel  opgenomen  kunnen  worden  in  een  netwerk,  zodat  een  grotere 
llexibiliteit  met  betrekking  tot  hun  inzet  verkregen  wordt  cn  tegelijkertijd  een 
gereduceerde  bezetting  van  personeel  mogelijk  is,  omdat  de  sensoren  niet  meer 
handmatig  uitgelezen  hoeven  te  worden. 

Gebruik  van  gedistribueerde  sensoren  in  een  samenhangend  netwerk  is  een 
veelbelovende  aanpak  om  compounds  beter  te  helpen  beveiligen.  In  de  afgelopen  jaren 
zijn  al  verschillende  onderzoeksopdrachten  uitgevoerd,  die  gericht  waren  op  detectie 
van  bewegende  objecten  in  een  ruimte.  Doorgaans  werd  een  bepaald  type  sensor 
gebruikt  tijdens  deze  studies,  dus  bijvoorbeeld  uitsluitend  radar  of  infrarood  of  daglicht 
camera’s.  Zo  heeft  TNO  in  2003  de  mogelijkheden  bestudeerd  om  met  zeer  kleine  en 
gedistribueerde  sensoren  het  gebied  rondom  een  compound  te  bewaken. 

De  bevindingen  van  dit  onderzoek  zijn  beschreven  in  [2].  Een  implementatie  van  dit 
systeem  met  een  groot  aantal  sensoren  werd  gedaan  binnen  het  project  SOWnet,  ook 
binnen  dit  programma  V2I9.  Deze  maakt  gebruik  van  bewegingsmelders  om  objecten 
rondom  de  compound  waar  te  nemen. 

2.3  Optreden  in  verstedelijkt  gebied 

Bij  sommige  operaties  zal  het  Nederlandse  leger  te  maken  hebben  met  optreden  in 
verstedelijkte  gebieden.  Dit  betekent  dat  er  in  een  dorp  of  een  stad  verkennings-  en 
patrouille  taken  te  verrichten  zijn  die  vaak  in  gevaarlijke  gebieden  gelegen  zijn. 

Om  het  risico  voor  het  militaire  personeel  te  minimaliseren  en  toch  een  goede  presentie 
te  behouden  kan  er  gebruik  gemaakt  worden  van  semi-autonome  robotsystemen. 

Zulke  robots  worden  op  afstand  bestuurd  en  kunnen  enkele  taken  zelfstandig  uitvoeren 
(bijvoorbeeld  obstakels  ontwijken  of  detectie  van  interessante  gebeurtenissen). 

Een  combinatie  van  een  aantal  robots  en  (uitgestrooide)  sensoren  kunnen  de  detectie- 
en  observatie-mogelijkheden  nog  verder  vergroten. 

2.4  Bescherming  vloot 

Marineschepen  in  (buitenlandse)  havens  zijn  kwetsbaar  tegen  terroristische  aanslagen. 
Denk  bijvoorbeeld  aan  de  USS  Cole  waar  met  behulp  van  een  rubberbootje 
verschillende  compartimenten  zijn  vernietigd  en  marinepersoneel  is  gedood. 

Het  gebruik  van  een  early  warning  system  kan  in  deze  gevallen  uitkomst  bieden. 
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Hierbij  valt  tc  dcnkcn  aan  sensoren  op  hct  schip,  rondom  hct  schip  in  hcl  water,  maar 
ook  op  de  kade.  De  opzet  van  een  dergelijk  sensor  network  moet  zodanig  zijn  dat  een 
sensor  die  stuk  gaat  direct  vervangen  kan  worden  door  een  werkend  exemplaar. 

De  methode  van  communicatie  moet  gestandaardiseerd  zijn  zodat  ook  nieuwe  sensoren 
eenvoudig  kunnen  worden  toegevoegd.  Door  de  aanwezigheid  van  lokale  intelligence 
zijn  de  sensoren  in  staat  om  problemen  met  de  communicatie  (bijvoorbeeld  te  veel 
zenders,  jamming,  et  cetera)  op  te  vangen.  Mogelijke  oplossingen  zijn:  automatische 
hertransmissie,  het  zoeken  van  een  ander  communicatie  pad  of  het  opslaan  van 
gegevens  en  deze  later  versturen  als  deze  tegen  de  tijd  van  herstelde  communicatie  nog 
actueel  zijn.  Een  mogelijk  nadeel  van  sensoren  is  de  false  alarm  rate.  Deze  kan  echter 
worden  verlaagd  door  de  detecties  van  een  aantal  sensoren  te  combineren. 

Bijvoorbeeld  een  bewegingsmelder,  sonar  en  een  camera,  of  een  radar  die  zijn  meting 
kalibreert  met  het  in  het  netwerk  aanwezige  meteorologisch  station.  Door  de  reductie 
van  false  alarms  wordt  de  operator  minder  belast  en  raakt  minder  vermoeid  waardoor 
deze  alerter  is  op  verdachte  situaties.  Dergelijk  snel  in  te  zetten  indringerdetectie- 
systemen  zijn  ook  te  gebruiken  in  (civiele)  havens  om  goederen  te  bewaken. 

2.5  Scheepsinspecties 

Een  belangrijke  taak  in  vredesoperaties  is  het  inspecteren  van  schepen.  Een  systeem  dat 
hierbij  behulpzaam  kan  zijn  is  een  combinatie  van  sensoren  zoals  satellietcn, 
radarsystemcn  aan  land  en  op  sehepen,  en  een  netwerk  van  intelligente  boeien. 

Het  combineren  van  de  informatie  afkomstig  van  deze  waarnemingsystemen  kan  leiden 
tot  het  dctectercn  en  onderscheppen  van  schepen  die  verdachte  routes  varen  (bijvoorbeeld 
rondjes  varen  maar  geen  havens  aandoen). 

2.6  Platformmanagement 

Om  calamiteiten  op  marine  schepen  adequaat  en  snel  het  hoofd  te  bieden  onderzoekt 
TNO  automatiseringsconcepten  gebaseerd  op  gedistribueerde  systemcn  [8]. 

Deze  systemen  monitoren  met  behulp  van  sensoren  de  technische  werking  van  een 
scheepsplatform  en  corrigeren  indien  nodig  autonoom  ongewenste  situaties. 

Voorbecld  van  systemen  die  op  deze  wijze  gemaakt  kunnen  worden  zijn  onder  andere: 
opwekking  en  verdeling  van  elektriciteit,  opwekking  en  verdeling  van  koudwater, 
opwekking  en  verdeling  van  brandbluswater,  opwekking  en  verdeling  van  hogedruk- 
en  lagedruklucht,  aangeven  evacuatie  of  beschikbare  routes  in  het  schip,  et  cetera. 

Robuustheid  van  een  dergelijk  platform-managementsysteem  kan  gerealiseerd  worden 
door  de  autonome  (bewaking  en  controle)  functies  zoveel  mogelijk  te  verdelen  over  het 
schip.  Wanneer  een  deel  van  het  systeem  uitvalt  blijven  bepaalde  kritische  functies 
locaal  functioneren  (bijvoorbeeld  pompen  inschakelen,  ruimtes  afsluiten,  et  cetera) 
waardoor  het  systeem  onafhankelijk  wordt  van  een  centrale  besturing.  Dit  vereist  een 
systeembenadering  die  in  staat  is  om  met  deze  ‘distribute  van  intelligence’  om  te  gaan. 
Dit  principe  wordt  in  het  project  ‘Robuuste  Automatisering’  (programma  Toekomstige 
Platformen,  V048)  onderzocht  door  TNO  voor  het  koudwatersysteem  uit  de 
hoofdfunctie  Support  SEWACO  (Sensoren-,  Wapen-  en  Commandosystemen). 

Het  koudwatersysteem  heeft  als  taak  het  opwekken  en  verdelen  van  koud  water. 

Het  koudwatersysteem  loopt  door  een  groot  deel  van  hct  schip.  De  correcte  werking 
wordt  gemonitord  d.m.v.  sensoren  met  lokale  intelligence.  In  geval  van  een  calamiteit 
(lekkages,  ongebalanceerde  koeling,  et  cetera)  wordt  met  behulp  van  actuatoren 
(kleppen,  cross-overs,  pompen,  et  cetera)  het  systeem  gereconfigureerd  zodat  de 
SEWACO  apparatuur  een  hogere  graad  van  beschikbaarheid  heeft  zonder  dat  een 
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operator  nodig  is  waardoor  een  hoge  reactiesnelheid  gewaarborgd  is.  Een  dergelijke 
oplossing  vereist  onder  andere:  sensoren  en  actuatoren  op  verschillende  locaties  op  het 
schip,  lokale  intelligentie  om  uitval  van  sensoren  te  compenseren  door  andere  routes  te 
genereren  en  een  robuust  netwerk  voor  dc  communicatie  tussen  de  sensoren  en 
actuatoren. 

2.7  Object  bewaking 

In  veel  gevallen  is  het  gewenst  dat  (militair)  materieel  bewaakt  wordt.  AIs  bijvoorbeeld 
een  helikopter  op  een  vliegveld  geland  is,  dan  dient  deze  voortdurend  bewaakt  te 
worden,  dag  en  nacht.  Hier  kunnen  genetwerkte  sensoren  een  belangrijke  rol  vervullen. 
Bewegings-detectoren  en  (infrarood)  camera’s  kunnen  rondom  het  te  bewaken  object 
gezet  worden.  Zodra  beweging  wordt  waargenomen  in  de  buurt  van  het  object  zal  de 
bewaker,  die  op  een  andere  plaats  kan  zitten,  geYnformeerd  worden.  Deze  vorm  van 
bewaking  is  veel  trcfzekerder  dan  alleen  visuele  inspectie.  Bovendien  kan  op  deze  wijze 
een  bewaker  meerdere  objecten  tegelijkertijd  bewaken. 
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3  Functionele  Beschrijving 


Dc  doelstelling  van  hct  Testbed  is  om  de  functionele  mogelijkheden  van  interoperabele 
devices  te  demonstreren.  Dit  is  echter  alleen  mogelijk  indien  hct  Testbed  beschikt  over 
gestandaardiseerde  protocollen  voor  data-  en  informatie  uitwisseling  tussen  de 
vcrschillende  onderdelen  van  hct  Testbed.  Deze  protocollen  worden  in  dit  hoofdstuk 
beschrcven. 

3.1  Inleiding 

De  bedoeling  van  het  Testbed  is  om  een  platform  te  creeren  dat  gebruikt  kan  worden 
om  systeemconcepten  op  het  gebied  van  gedistribueerde  waameming  te  evalueren. 

In  principe  komt  het  er  op  neer  dat  verschillende  systemen  (sensoren  en/of  actuatoren) 
met  elkaar  moeten  kunncn  ‘samenwerken’  om  een  meerwaarde  te  leveren  aan  de 
kwaliteit  van  de  waarnemingen.  Het  Testbed  zal  dus  een  infrastructuur  moeten  leveren 
die  data  van  verschillende  soorten  sensoren  kan  uitlezen  en  ook  actuatoren  kan 
aansturen.  We  spreken  hier  dus  over  een  ‘system  of  systems’  (tegenwoordig  ook  wel 
‘system  of  platforms’  genoemd).  Bovendien  zal  het  Testbed  in  staat  moeten  zijn  om 
data  van  sensoren  te  fuseren  en  te  evalueren. 

Zo’n  gewenste  infrastructuur  kan  alleen  tot  stand  komen  als  er  een  aantal  functies 
gestandaardiseerd  zijn,  te  weten: 

1  Netwerk.  Apparaten  zijn  alleen  bruikbaar  als  ze  een  netwerkaansluiting  bezitten 
voor  een  bepaald  netwerkprotocol. 

2  Communicatie-interfcice.  Om  data  uit  te  Iezen  en  apparatuur  aan  te  sturen  moet  er 
een  communicatie-protocol  zijn  voor  het  uitwisselen  van  berichten. 

Zonder  standaard  protocol  is  samenwerking  niet  mogelijk.  Dit  kan  vergeleken 
worden  met  de  syntax  of  grammatica  van  een  taal. 

3  Data-interpretatie.  Als  het  netwerk  draait  en  er  data  verzonden  kan  worden,  dan 
moet  de  data  nog  geinterpreteerd  worden.  Als  hier  geen  afspraken  over  gemaakt 
zijn  dan  begrijpen  ze  elkaar  niet  (de  apparaten  moeten  alien  dezelfde  ‘taal 
spreken’).  Dit  kan  vergeleken  worden  met  de  semantiek  of  betekenis  van  woorden 
in  een  taal. 

Wat  bctreft  het  netwerk:  de  meeste  apparaten  met  een  netwerk-interface  zullen  een 
gangbare  standaard  kiezen,  zoals  ethemet  met  TCP/IP,  Bluetooth  of  GPRS.  Dit  is  dus 
geen  probleem  voor  integratie  in  het  Testbed  dat  in  principe  al  deze  protocollen  kan 
afhandelen. 

Lastiger  wordt  het  doorgaans  bij  het  vaststellen  van  wat  er  over  het  netwerk  gestuurd 
wordt  per  apparaat.  Zelfs  als  het  netwerk  ethernet  is  met  lOOMbits/s  en  het  netwerk¬ 
protocol  TCP/IP,  dan  is  nog  steeds  niet  bekend  hoe  een  gebruiker  data  uit  dat  apparaat 
(een  sensor)  kan  krijgen  en  hoe  die  vervolgens  te  interpreteren.  Vaak  wordt  bij  ieder 
apparaat  een  communicatie-protocol  meegeleverd  waarin  staat  op  welke  manier 
bepaalde  parameters  ingesteld  moeten  om  data  te  kunnen  lezen.  De  data  wordt  dan  in 
een  bepaald  formaat  geleverd  dat  vaak  heel  specifiek  is  voor  dat  apparaat.  Er  is  dus 
vaak  geen  standaard,  noth  voor  het  communicatie-protocol  noch  voor  het  data-protocol. 
Dit  probleem  kan  worden  ondervangen  door  te  proberen  deze  interfacing  te 
standaardiseren.  In  de  volgende  paragraaf  wordt  een  methode  geYntroduceerd  om  dit  te 
realiseren 
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3.2  Networked  Intelligent  Devices 

Een  typische  Testhcd-applicatie  hcstaat  uit  een  aantal  sensoren,  actuatoren  cn 
gebruikers  die  informatie  uitwisselen  via  een  netwerk.  Een  sensor  kan  worden 
beschreven  als  een  instrument  dat  in  staat  is  om  een  fenomeen  te  observeren  en  de/e  te 
vcrtalen  in  een  getal  of  een  verzameling  getallen.  Een  actuator  is  een  instrument  dat  in 
staat  is  om  zijn  omgeving  te  beYnvloeden.  Een  controller  device  kan,  via  een  operator  of 
autonoom,  acties  ondernemen  om  de  werking  van  de  applicatie  te  beYnvloeden. 

Ook  de  interactie  met  de  gebruiker  is  een  taak  voor  een  controller  deviee:  de  gebruiker 
kan  commando’s  geven  of  informatie  aflezen.  In  dit  verband  wordt  de  term  NID 
(Networked  Intelligent  Device)  gebruikt  voor  elk  apparaat  (sensor,  actuator  of 
controller  (gebruiker))  dat  onderdeel  uitmaakt  van  het  netwerk.  Figuur  3. 1  toont  een 
principe-schema  van  een  Testbed-systeem.  Elke  ovaal  in  deze  figuur  is  een  soort  NID. 
Er  zijn  dus  sensor-NIDs,  actuator-NIDs  en  gebruiker-NIDs. 


Figuur  3. 1  Principe-schema  van  een  typische  Testbed-toepassing. 

De  NIDs  delen  informatie  via  het  datanetwerk.  De  sensoren  (bijvoorbeeld  radar  of 
electro-optisch)  observeren  de  omgeving  terwijl  de  actuatoren  (bijvoorbeeld  jammers) 
gebaseerd  op  de  sensorinformatie  de  omgeving  manipuleren.  Met  behulp  van 
beeldschcrmen  wordt  de  verkregen  informatie  zichtbaar  gemaakt  aan  de  gebruiker  die 
vervolgens  eventueel  actie  kan  ondernemen. 

Een  NID  bevat  functies  met  betrekking  tot  het  Testbed  en  functies  met  betrekking  tot  de 
applicatie  die  gebruik  maakt  van  de  Testbed  omgeving.  Om  te  komen  tot  een  goede 
definitie  van  het  Testbed  is  het  belangrijk  om  een  onderscheid  te  maken  tussen  de 
functies  van  het  Testbed  zelf  en  de  applicaties  die  gebruik  maken  van  het  Testbed. 
Daarom  onderscheiden  we  twee  modules: 

1  De  NID  Module. 

2  De  Applicatie  Module. 

Deze  scheiding  in  modules  is  weergegeven  in  figuur  3.2.  Elke  module  kan  op  zijn  beurt 
weer  opgesplitst  zijn  in  andere  modules.  De  NID  Module  vormt  de  verbinding  met  het 
netwerk  en  levert  diensten  aan  de  Applicatie  Module.  De  Applicatie  Module  bevat  de 
applicatie-software  (signaalverwerking  en  dergelijke).  Om  ervoor  te  zorgen  dat  beide 
modules  goed  op  elkaar  aansluiten  en  dat  de  applicatie-ontwikkelaar  exact  weet  hoe  de 
applicatie  kan  worden  getest  op  het  Testbed  wordt  gebruik  gemaakt  van  een  API 
(Application  Program  Interface),  die  de  applicatie-ontwikkelaar  gemakkelijk  toegang 
verschaft  tot  de  functionaliteiten  van  de  NID-module. 
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Figuur  3.2  Modules  binnen  een  NID. 


Voor  specifieke  applicatics  kan  hct  voorkomen  dat  de  resources  (rekenkracht,  geheugen, 
et  cetera)  van  de  NID  niet  toereikend  zijn.  In  dergelijke  gevallcn  kan  de  applicatie 
ontwikkelaar  natuurlijk  ook  gebruik  maken  van  een  eigen  werkstation  met  daaraan  de 
sensor.  Dit  werkstation  communiceert  vervolgens  zijn  bevindingen  naar  de  NID 
module,  zie  figuur  3.3.  De  wijze  van  communicatie  tussen  het  werkstation  en  het  device 
valt  volledig  onder  de  verantwoording  van  de  applicatie  ontwikkelaar. 

Daarnaast  is  het  natuurlijk  ook  mogelijk  dat  de  applicatie  ontwikkelaar  het  werkstation 
direct  aansluit  op  het  netwerk  waarbij  de  NID  module  op  het  werkstation  wordt 
gei'mplementecrd. 


Figuur  3.3  Uitbreiding  van  de  Applicatie  Module  als  een  NID  zelf  onvoldoende  resources  heeft  zoals 
rekenkracht,  geheugen  of  als  de  sensorinterface  niet  voldoet. 


Door  de  API  eenduidig  te  specificeren  hoeft  de  applicatie  ontwikkelaar  geen  kennis  te 
hebben  van  de  wijze  van  communicatie  over  het  netwerk.  Dit  wordt  immers  verzorgd 
door  de  NID  module.  Door  deze  scheiding  kan  in  principe  elk  type  netwerk  met 
bijbehorende  protocollen  worden  gebruikt  binnen  de  Testbed  Omgeving  zonder  dat  de 
Applicatie  Module  hoeft  te  worden  aangepast. 
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In  sommige  situaties  is  het  nict  praktisch  of  realisecrbaar  om  de  fysickc  meting  met  het 
Testbed  uit  te  voeren.  Bijvoorbeeld  omdat  de  meetdata  afkomstig  is  van  de  sensoren 
van  een  operationeel  scheepsplatform  of  omdat  het  wenselijk  is  om  een  specifiek 
scenario  te  testen.  In  deze  situaties  is  het  wenselijk  om  de  opgenomen  meetdata  kaf  te 
spelen’  in  het  Testbed.  Voor  dergelijke  situaties  kan  gebruik  worden  gemaakt  van 
replay  NIDs.  In  deze  NIDs  bestaat  de  Applicatie  Module  alleen  uit  software  en  is  er  dus 
geen  sensor  of  actuator,  zie  figuur  3.4.  De  software  simuleert  de  aanwezigheid  van  de 
sensor  of  actuator. 


Figuur  3.4  De  modules  in  een  replay  NID  en  een  virtuele  NID. 


Een  stap  verder  is  het  emuleren  van  de  gehele  NID  in  software  d.m.v.  een  virtuele  NID 
(zie  figuur  3.4).  Hiermee  is  het  zelfs  mogelijk  om  een  deel  van  het  netwerk  te  simuleren 
op  bijvoorbeeld  een  werkstation.  Een  test  applicatie  bestaat  dan  uit  een  virtueel  netwerk 
met  virtuele  NIDs  en  een  fysiek  netwerk  met  fysieke  devices  en/of  replay  NIDs. 

Dit  is  gevisualiseerd  in  figuur  3.5. 


Workstation 


Figuur  3.5  Combinatie  van  virtuele  NIDs,  replay  NIDs  en  NIDs. 

In  de  volgende  paragrafen  wordt  beschreven  hoe  de  NIDs  gebruikt  kunnen  worden  om 
de  interfacing  tussen  apparaten  te  standaardiseren. 
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3.3  Communicatie-interface 

Hct  Testbed  is  opgcbouwd  uit  een  netwerkinfrastructuur  dat  gebruik  maakt  van  de 
‘.NET’  omgeving  van  Microsoft.  Devices  kunnen  zich  aanmelden  met  behulp  van  een 
XML-file  conform  het  DeviceML-schema  protocol  (zie  §3.7).  De  devices  vinden  elkaar 
op  het  netwerk  door  een  ‘service  request’  naar  een  lookup  service  te  sturen.  Nadat  NIDs 
elkaar  gevonden  hebben  kunnen  ze  communiceren  door  zgn.  UCM  berichten  uit  te 
wisselen.  Hieronder  worden  deze  functies  nader  uitgelegd. 

3.4  Het  onderliggende  platform  .NET 

Voor  de  implementatie  van  het  Testbed  is  gekozen  voor  de  .NET  omgeving.  Dit  is  een 
software  platform  van  Microsoft  dat  uitermate  geschikt  voor  het  opzetten  van  het 
Testbed  omdat  er  een  uitgebreide  ondersteuning  aanwezig  is  van  software-bibliotheken 
voor  netwerkfuncties.  Hierdoor  kunnen  er  snel  gedistribueerde  data-netwerken  opgezet 
worden  om  gedistribueerde  waarnemingsconcepten  te  testen. 

Bovendien  is  .NET  zeer  geschikt  om  met  XML  te  werken.  Dit  is  zeer  gunstig  omdat  het 
Testbed  veelvuldig  van  XML  gebruik  maakt,  zoals  bij  de  aanmeldingen  van  de  devices 
(DeviceML),  bij  Service  Discovery  en  bij  de  data-uitwisseling.  Alleen  binnen  een  NID, 
dat  in  feite  ook  uit  verschillende  programma’s  bestaat,  wordt  geen  gebruik  gemaakt  van 
XML. 

Een  nadecl  van  de  .NET  omgeving  is  wel,  dat  elk  device  over  een  behoorlijk  grote 
capaciteit  (geheugen  en  processorkracht)  moet  beschikken  om  de  onderliggende. 

NET  infrastructuur  te  kunnen  ondersteunen;  minimaal  een  Pentium  II  is  nodig. 

Op  dit  moment  draait  .NET  uitsluitend  op  Microsoft  Windows,  hetgeen  niet 
overeenkomstig  de  oorspronkelijke  doelstelling  van  het  Testbed  is  om  verschillende 
platformen  te  ondersteunen  [  1 ).  Met  name  het  wijdverbreide  Linux  dient  ondersteund  te 
worden.  Gelukkig  wordt  er  momenteel  ook  een  .NET  versie  voor  Linux  ontwikkeld 
waar  binnenkort  gebruik  van  gemaakt  kan  worden. 

3.5  Lookup  service 

Binnen  een  gedistribueerd  waarnemingsysteem  wordt  data  tussen  NIDs 
gecommuniceerd,  met  als  doel  om  door  de  combinatie  van  de  verschillende  observaties 
een  betere  en  betrouwbaardere  detectie,  classificatie  of  identificatie  te  verkrijgen  van  de 
gedetecteerd  objecten. 

Voordat  dit  communicatieproces  op  gang  kan  komen  moeten  de  NIDs  elkaar  op  het 
netwerk  gevonden  hebben.  Een  goede  aanpak  is  om  gebruik  te  maken  van  een  soort  lijst 
die  de  eigenschappen  van  alle  NIDs  bijhoudt.  Deze  lijst  kan  gelezen  worden  door  alle 
NIDs  in  het  netwerk.  Zodra  nu  een  NID  een  typische  functionaliteit  wenst  dan  kan  hij 
die  bij  de  lijst  opvragen  en,  indien  aanwezig,  krijgt  hij  referenties  naar  die  NID(s)  terug 
die  de  gewenste  functionaliteit  kunnen  bieden.  Deze  faciliteit  wordt  aangeboden  door 
de  ‘LookUp  Service’  (LUS).  Het  bijbehorende  zoekproces  heel  ‘Service  Discovery’. 

Bij  de  LUS  staan  dus  de  eigenschappen  van  alle  NIDs  in  het  netwerk. 

De  eigenschappen  zijn  weergegeven  door  middel  van  DeviceML  beschri  jvingen 
(zie  paragraaf  3.7). 
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Dit  proces  kan  worden  ge-illustreerd  met  een  voorbeeld.  Stel  dat  een  gebruiker  de  taak 
heeft  om  bewegende  objecten  op  een  veld  waar  te  nemen.  Hierbij  wil  hij  gebruik  maken 
van  gedistribueerde  waarneming.  Hij  installeert  twee  sensortypes  die  de  waarneming 
moeten  verzorgen,  te  weten  een  radarsysteem  en  een  infrarood  camera.  Deze  twee 
systemen  zijn  in  feite  NIDs.  Deze  melden  zich  op  het  netwerk  aan. 

Om  nu  gedistribueerde  waarneming  te  kunnen  plegen  moet  de  data  van  die  sensoren 
samengevoegd  worden.  Dit  gebeurt  bij  een  derde  NID  in  het  netwerk,  de  ‘fusie-NID’. 
Deze  laatste  zoekt  op  het  netwerk  naar  NIDs  die  bewegende  objecten  kunnen 
detecteren.  Hij  zend  hiervoor  een  verzoek  naar  de  LUS  om  alle  data  van  NIDs  te  mogen 
ontvangen  die  de  service  ‘bewegende  objecten’  aanbieden.  Na  ontvangst  van  een 
verbinding  naar  elk  van  deze  NIDs,  kan  hij  ze  contacteren.  In  dit  voorbeeld  zijn  dat  de 
intrarood-sensor-NID  en  de  radar-NID.  Hiema  bestaat  er  een  verbinding  tussen  de 
fusie-NID  en  de  beide  sensor-NIDs.  Nu  kan  datafusie,  om  objecten  te  detecteren  met 
gedistribueerde  sensoren,  op  de  fusie-NID  plaatsvinden  door  de  data  van  de  beide  NIDs 
te  combineren.  Dit  lijkt  een  ingewikkelde  procedure  voor  slechts  twee  sensoren. 

Echter  in  een  omvangrijk  systeem  met  veel  verschillende  sensoren  en  services,  is  deze 
aanpak  zeer  gewenst. 

De  Lookup  service  heeft  dus  een  centrale  rol  binnen  het  Testbed.  Bij  de  LUS  staan  alle 
(actieve)  devices  geregistreerd  en  geldt  als  een  soort  ‘gouden  gids’  voor  alle  NIDs  in 
het  netwerk.  Hieronder  wordt  het  proces  van  aanmelding  door  NIDs  (ook  wel  ‘join 
genoemd’)  en  het  zoeken  naar  functies  van  andere  NIDs  (‘service  discovery’) 
stapsgewijs  beschreven. 

3. 5. 1  Aanmelden/registreren  van  NIDs  (join ) 

Zodra  een  NID  bij  het  netwerk  dient  te  worden  aangesloten  wordt  deze  procedure 
gevolgd: 

•  de  LUS  luistert  op  een  groep-adres  (op  port:  1 1000)  naar  UDP  berichten  voor 
eventuele  NID-aanmeldingen; 

•  de  NID  start  op  en  stuurt  een  UDP  bericht.  Dit  bericht  is  in  XML  beschreven  en 
heeft  de  vorm: 


<?xml  version="1 .0"?> 

<Config> 

<Startup> 

<OwnAddress>1 0.0 .0.1 1  </OwnAddress> 

<ContactPort>1 1 01 2</ContactPort> 

=:lnrtialDataFile>init_data.xml<.1nitialDataFile> 

</Startup> 

<GetCSDInfo> 

<CSDPort>1 0000<CSDPort> 

</GetCSDInfo> 

<GetDeviceMLInfo> 

<DeviceMLPort>1 1 01 1  <.0eviceMLPort> 

-DeviceMLFile>CSD.xml<£>eviceMLFile> 

<A3etDeviceMLInfo> 

</Config> 

Figuur  3.6  Het  formaat  van  het  UDP-bericht  dat  een  NID  naar  de  LUS  stuurt  voor  aanmelding.  De  LUS 
kan  hieruit  het  IP-adres  en  portnummer  van  de  NID  halen.  Ook  de  naam  van  de  XML-file  om 
de  NID  te  beschrijven  staat  hierin  vermeld  (in  dit  geval  ‘CSD.xml’)  in  DeviceML  formaat. 

Dit  wordt  door  de  LUS  opgehaald  en  in  zijn  lijst  van  NIDs  geplaatst. 
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•  Na  ontvangst  van  een  bericht  van  een  NID  wordt  het  IP-adres  van  de  NID  uit  het 
bericht  geextraheerd. 

•  Vervolgens  wordt  het  NID  IP-adres  gebruikt  door  de  LUS  om  de  DeviceML 
beschrijving  van  de  NID  op  te  halen.  Dit  wordt  gedaan  door  een  TCP/IP  verbinding 
op  te  zetten  tussen  de  LUS  en  de  NID  (via  de  DeviceML  port). 

•  De  DeviceML  beschrijving  wordt  dan  gevalideerd  door  de  LUS. 

•  Als  de  DeviceML  beschrijving  correct  is,  dan  wordt  deze  opgenomen  in  de  actieve 
sensorenlijst  van  de  LUS. 

•  Als  de  DeviceML  beschrijving  niet  correct  is,  dan  wordt  deze  geweigerd  door  de 
LUS  en  een  bericht  wordt  verstuurd  naar  de  NID.  Dit  bericht  wordt  afgevangen 
door  de  NID  en  een  bericht  naar  de  (menselijke)  eigenaar  ervan  wordt  verstuurd. 

3.6  Zoeken  naar  devices  (service  discovery) 

Zodra  een  NID  een  gewenste  functionaliteit  zoekt  (zoals  bijvoorbeeld  een  infrarood- 

camera  die  object-informatie  kan  aanleveren)  worden  de  volgende  stappen  doorlopen: 

•  De  LUS  luistert  voortdurend  naar  berichten  van  al  geregistreerde  NIDs 
(op  port  11001). 

•  NIDs  zoeken  bij  de  LUS  naar  bepaalde  functionaliteiten  geleverd  door  andere 
NIDs.  Ze  doen  dit  door  een  bepaalde  beschrijving  naar  de  LUS  toe  te  sturen  (via 
TCP/IP).  Zo’n  beschrijving  heeft  de  vorm: 

<?xml  version="1 .0"?> 

<Sensor> 

<ldentifiedAs> 

<T  ypeOf  Sensor>radar<.«T  ypeOf  Sensor> 

<ddentifiedAs> 

</Sensor> 

Figuur  3.7  Voorbeeld  van  een  zoekopdracht  voor  een  sensor  van  het  type  ‘radar’.  De  vragende  NID  stuurt 
dit  bericht  naar  de  LUS.  Mogelijke  types  zijn  gedefinieerd  in  DeviceML. 


•  Vervolgens  zal  de  LUS  in  de  actuele  deviceslijst  controleren  welke  NIDs  voldoen 
aan  het  verzoek  en  een  lijst  terugsturen  met  daarin  het  IP-adres  van  de  NIDs  die 
voldoen  aan  de  beschrijving. 

•  De  vragende  NID  kan  nu  via  de  verkregen  IP-adres(sen)  contact  leggen  met  de 
NIDs  die  de  gewenste  dienst  kunnen  bieden. 

3.6. 1  Up-to-date  houden  van  de  aanmeldingen  (leasing) 

De  LUS  elimineert  na  verloop  van  tijd  zelf  oude  aanmeldingen  van  de  lijst  omdat  de 
bijbehorende  NIDs  niet  meer  bereikbaar  zijn,  bijvoorbeeld  omdat  deze  buiten 
zendbereik,  uitgeschakeld  of  defect  zijn.  Een  NID  is  er  zelf  verantwoordelijk  voor  dat 
zijn  aanmelding  regelmatig  wordt  hemieuwd  indien  deze  zijn  aanmelding  wil 
behouden.  De  NID  stuurt  daarom  regelmatig  een  ‘heartbeat’  signaal  naar  de  LUS. 

Als  de  LUS  van  een  NID  een  aantal  seconden  geen  heartbeat  heeft  ontvangen  dan  wordt 
deze  verwijderd  uit  de  lijst. 
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3.7  DeviceML 

Na  aanmelding  van  een  NID  haalt  de  LUS  de  DeviceML  beschrijving  ervan  op. 
Vanwege  de  complexiteit  en  kostbaarheid  om  standaarden  in-huis  te  ontwikkelen,  is 
ervoor  gekozen  om  gebruik  te  maken  van  de  concepten  die  ontwikkeld  worden  binnen 
het  sensor  web  enablement  program  (SWEP)  [3]  van  het  Open  GIS  consortium  (OGC) 
[4].  Dit  programma  binnen  het  OGC  heeft  als  doelstelling  te  komen  tot  een  open 
platform  voor  het  gebruiken  van  ‘web-enabled  sensors’.  SensorML  [5]  en  Observations 
and  Measurements  (O&M)  [6]  zijn  hieruit  ontstaan.  Deze  zijn  gerelateerd  aan 
aardobservatiesystemen . 

Echter,  deze  standaarden  zijn  te  ruim  opgezet  en  te  complex  samengesteld  om  direct 
gebruikt  te  kunnen  worden  in  het  Testbed.  Een  ander  nadeel  ervan  is  dat  ze 
uitsluitend  geschikt  zijn  om  sensoren  te  beschrijven  en  dus  geen  actuatoren. 

Dat  betekent  dat  er  geen  controle-berichten  met  deze  protocollen  gedefinieerd 
kunnen  worden.  Bovendien  zijn  deze  standaarden  nog  in  ontwikkeling. 

Vandaar  dat  er  besloten  is  om  voor  het  Testbed  een  ietwat  afwijkend  protocol  te 
definieren,  gestoeld  op  de  ideeen  vanuit  SensorML  en  O&M.  Dit  protocol  hebben  we 
‘DeviceML’  genoemd.  Dit  is  een  generieke  beschrijving  voor  elk  device  dat  in  het 
Testbed  opgenomen  dient  te  worden.  In  XML  heet  zo’n  omschrijving  een  ‘schema’. 
DeviceML  is  geschikt  voor  alle  devices,  het  is  simpel  en  doeltreffend  in  zijn  opzet  en 
geschikt  voor  de  doelstellingen  van  het  Testbed.  In  figuur  3.8  is  het  XML-schema 
weergegeven. 


Figuur  3.8  DeviceML  schema  voor  de  Testbed  omgeving. 

Gebruik  makend  van  DeviceML  kan  een  device  gedefinieerd  worden  met  behulp  van 
een  XML-file  die  conform  dit  formaat  geconstrueerd  is.  In  figuur3.9  staat  een  voorbeeld 
van  zo’n  XML  file  voor  een  radar  sensor. 
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<?xml  version="1 .0"  encoding="UTF-8"?> 

<Device> 

<ldentifiedAs> 

=  shortName>Radar  sensor</shortName> 

<T  ypeOf  De  vice>radar</T  ypeOf  Device* 

<.«ldentifiedAs> 

<Observable> 

<Address>1 0.0. 0.1 1  </Address> 

<ContactPort>1 1 033-=XontactPort> 

<DataPort>1 1 032<)DataPort> 

<DataT  ype>UCM<.'DataT  ype> 

<UpdateSpeed>1000<AJpdateSpeed= 

</Observable> 

<£>evice> 

Figuur  3.9  Voorbceld  van  een  XML  file  voor  een  radar  sensor,  gebaseerd  op  de  DeviceML  schema 
beschrijving  uit  Figuur  3.8. 


3.8  Data-uitwisseling 

Het  uitwisselen  van  data  tussen  de  NIDs  kan  plaatsvinden  nadat  ze  elkaar  hebben 
gevonden  en  een  verbinding  hebben  gecreeerd  op  de  ContactPort  (zie  figuur  3.9). 

Het  data-formaat  dat  voor  het  Testbed  is  gekozen  is  een  formaat  dat  door  TNO  reeds 
gebruikt  werd  om  ‘tracks’  van  waamemingen  vast  te  leggen.  Dit  formaat  is  ‘Universal 
Contact  Message*  (UCM)  genoemd.  Dit  formaat  is  gedefinieerd  als  weergegeven  in 
tabel  2.1  (zie  ook  Bijlage  A). 


Tabel  3.1  UCM  formaat. 


field 

format 

description 

big/little  endian 

identifier 

U41 

always  contains  number  0x12345678 

sensor  id 

U4 

unique  sensor  number  for  specific  measurement  setup 

message  id 

U4 

serial  number  for  blocks  of  contacts  from  one  sensor, 
for  each  sensor  this  number  starts  with  1 

number  of  contacts 

U4 

number  of  contacts  in  message 

header  format  id 

U4 

header  format  number 

contact  format  id 

U4 

contact  format  number 

1  U4  means  unsigned  integer  of  4  bytes 


3.9  Samenvattend 

Hiermee  is  de  functionaliteit  van  het  Testbed  beschreven.  Ieder  device  (NID)  dat 
aangesloten  dient  te  worden  op  deze  omgeving  wordt  omschreven  met  de 
gestandaardiseerde  XML-beschrijving  (DeviceML),  zodat  communicatie  tussen 
devices,  en  de  rest  van  het  netwerk,  gegarandeerd  is.  Daarna  vind  data-communicatie 
plaats  over  de  ContactPort  in  het  UCM-formaat.  In  de  volgende  hoofdstukken  wordt 
een  scenario  en  demonstratiesysteem  beschreven  dat  van  dit  Testbed  gebruik  maakt. 
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4  Demonstratiesysteem 


De  hier  bcschreven  applicatie  demonstrecrt  ecn  bewakingsysteem  dal  in  ccn  compound- 
beveiligingsystccm  gcbruikl  zou  kunncn  wordcn.  Dc  taak  van  hcl  sysleem  is  dc  detectie 
van  bcwcgendc  objecten  cn  hct  tracken  van  dcze  objecten  met  verschillende  soorten 
sensoren.  Dc  objecten  zijn  bijvoorbeeld  insluipers  in  het  gebied  rondom  de  compound. 
De  gekozen  sensoren  zijn  radar,  infrarood  en  bewegingsmelders.  Deze  keuze  is  gemaakt 
omdal  defensie  vaak  gebruik  maakt  van  deze  typen  sensoren. 

4. 1  Demonstratiesysteem 

De  architectuur  van  het  demonstratiesysteem  is  getoond  in  figuur  4. 1 .  De  volgende 
systeemcomponenten  voordit  bewakingsysteem  kunnen  hierin  herkend  worden: 

-  een  infrarood  camera  (IR); 

-  een  radarsysteem  (Radar); 

-  een  set  bewegingsmelders  die  een  autonome  sensorgroep  vormen  (CSD); 

-  een  informatiefusiesysteem  (M6T); 

-  een  monitor  station  (Display  Server:  DS); 

-  een  eontrollestation  voor  diverse  instellingen  (CS); 

-  het  systeem  is  optioneel  uit  te  breiden  met  een  Personal  Digital  Asistant  (PDA), 
die  bijvoorbeeld  gehanteerd  wordt  door  bewakingpersoneel. 


Figuur  4. 1  De  architectuur  van  het  demonstratie  systeem. 


De  sensoren  worden  op  strategische  locaties  geplaatst  om  hun  taak  goed  te  kunnen 
verrichten.  Dat  betekent  dat  de  bewegingsensoren  verdeeld  worden  in  het  gebied  rond 
de  compound.  De  radar  en  infrarood  camera  worden  opgesteld  in  het  centrum  van  de 
compound.  In  figuur  4.2  is  dit  grafisch  weergegeven. 


TNO-rapport  |  TNO-DV1  2005  A153 


21  /  32 


infrarood 

camera 


control 

centre 


daglicht 


Compound  area 


Buffer  zone 


beweging 

sensoren 


0-0 


weg 


o-o- 


Figuur  4.2  Hct  practische  demonstratie-scenario.  Een  compound  is  volledig  omringd  door  een  dubbcle 
ring  van  sensoren.  De  infrarood  camera  en  het  radarsysteem  in  de  compound  worden 
geinformeerd  door  de  bewegingsensoren  en  zullen  activiteiten  in  de  gebiedjes  rondom  de 
actieve  sensoren  registreren.  De  demonstratie  gebruikt  4  bewegingsensoren.  De  M6T  fuseert  deze 
data  tot  tracks.  De  daglicht  camera  wordt  alleen  gebruikt  voor  visuele  in  spec  ties  door  de  operator. 

De  rest  van  clit  hoofdstuk  behandelt  de  versehillende  sensormodules  en  hun  specifieke 
waarnemingstaak  in  het  eompound  security  demonstratiesysteem.  Dit  zijn  radar, 
infrarood  en  een  set  bewegingsmelders. 

4.2  Radar  module 

Een  radar-sensor  is  met  name  geschikt  om  afstanden  tot  objecten  te  meten. 

Bovendien  is  het  mogelijk  om  te  meten  met  welke  snelheid  een  obstakel  zich  beweegt 
door  de  afstandsmetingen  in  de  tijd  uit  te  zetten. 

Zulke  gecombineerde  metingen  (afstand  en  snelheid)  worden  gedaan  met  een  FMCW 
radar.  Een  FMCW  radar  zendt  een  bepaalde  elektromagnetische  golf  (continuous  wave 
of  CW)  uit  met  een  varierende  frequence,  dit  laatste  wordt  frequentie-modulatie  (FM) 
genoemd. 

In  prineipe  wordt  het  FMCW  signaal  uitgezonden  in  ‘sweeps’  van  rond  de  1  ms. 

Een  sweep  bestaat  uit  een  puls  waarin  de  uitgezonden  frequence  gestaag  wordt 
verhoogd,  uitgaande  van  de  basisfrequentie.  De  basisfrequentie  die  voor  de 
demonstratie  wordt  ingesteld  is  rond  de  2.5  GHz. 

In  een  sweep  wordt  bijvoorbeeld  de  frequence  verhoogd  met  250  MHz. 

Hierbij  wordt  de  uitgezonden  frequentie  bijvoorbeeld  lineair  verhoogd  van 
2.30  GHz  tot  2.55  GHz. 
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Dit  signaal  wordt  in  de  richting  van  het  object  gezonden  waarvan  de  afstand  en  snelheid 
tot  de  radarsensor  gemeten  moet  worden.  Het  door  het  object  gereflecteerde  signaal  is 
een  maat  voor  zijn  afstand  tot  de  radar.  In  figuur  4.3  is  dit  proces  grafisch  weergegeven. 
Het  gereflecteerde  signaal  wordt  door  de  radar  gemeten.  Het  gemeten  frequentieverschil 
Af  geeft  het  verschil  aan  tussen  de  uitgezonden  en  de  ontvangen  frequentie.  Hoe  groter 
de  afstand,  hoe  groter  Af.  De  afstand  tot  het  object  kan  hieruit  berekend  worden  door 
gebruik  te  maken  van  de  snelheid  van  het  uitgezonden  signaal,  dat  wil  zeggen  de 
lichtsnelheid.  Bovendien  geeft  de  intensiteit  van  het  gereflecteerde  signaal  een  indicatie 
voor  de  omvang  van  het  object. 

frequency 


transmitted 


reflected  1 
reflected  2 


Figuur  4.3  FMCW  radarsignalen  voor  afstandsmetingen.  Het  ‘reflected  1  ’  signaal  geeft  een  object  op  korte 
afstand  aan,  het  ‘reflected  2’  signaal  toont  een  object  op  grotere  afstand. 

Door  het  herhaald  uitzenden  van  sweeps  in  een  bekend  ritme,  kan  de  snelheid  van  het 
object  worden  bepaald.  Dit  wordt  gedaan  door  de  veranderingen  in  de  Af  metingen  te 
beschouwen.  Om  dit  verder  te  verduidelijken  is  in  figuur  4.4  een  ‘range-velocity’ 
diagram  getekend.  Op  de  horizontale  as  staat  de  range  (afstand)  en  op  de  verticale  as 
staat  de  velocity  (snelheid).  De  lijn  in  het  midden  representeert  snelheid  nul. 

Dus  de  meetpunten  op  deze  lijn  geven  objecten  aan  die  stil  staan  op  de  getoonde 
afstand.  Meetpunten  boven  of  onder  deze  lijn  indiceren  bewegende  objecten. 


Figuur  4.4  Range-velocity  diagram. 
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Typische  maximale  mectdata  voor  onze  radar  zijn: 

-  maximale  detectieafstand:  2(X)  m; 

-  meetresolutie:  60  cm; 

-  maximale  deteetiesnelheid:  1 10  km/hr; 

-  meetresolutie:  1 .8  km/hr. 

Voor  de  demonstratie-opstelling  beschrcven  in  dit  rapport  wordt  gebruik  gemaakt  van 
het  CFAR  (Constant  False  Alarm  Rate)  algoritme.  Dit  algoritme  maakt  gebruik  van 
bovenstaande  range-velocity  diagrammed 

Het  CFAR  algoritme  genereert  een  lijst  met  alle  detecties,  ook  wel  contacten  genoemd. 
De  metingen  worden  geclusterd.  Dat  betekent  dat  contacten  die  dicht  bij  elkaar  liggen 
wat  betreft  snelheid  en  afstand,  gegroepeerd  zijn.  Dit  is  zeer  behulpzaam  bij  het 
detecteren  van  loze  alarmen.  Een  loos  alarm  is  een  meting  van  een  object  dat  er  in  feite 
niet  is.  Dcze  genereren  doorgaans  kleinere  clusters  dan  in  het  geval  van  detecties  van 
echt  aanwezige  objecten. 

4.3  Infrarood  module 

Voor  het  opbouwen  van  een  warmtebeeld  van  de  omgeving  worden  infrarood  camera’s 
gebruikt.  In  het  bijzonder  mensen  en  dieren  kunnen  op  deze  wijze  zeer  goed 
gedetecteerd  worden.  Met  een  infrarood  camera  kan  er  dus  ook ’s  nachts  gedetecteerd 
worden.  In  combinatie  met  een  detectie  algoritme  zoals  in  de  volgendc  paragraaf  is 
beschrcven,  is  dan  een  zeer  lage  vals  alarm  kans  te  realiseren. 

Een  infrarood  camera  detecteert  straling  in  een  bepaald  golflengtegebied.  De  voor  deze 
demonstratie  gebruikte  camera’s  zijn  een  Thermacam  of  een  Radiance  IT.  Beide  zijn 
gevoelig  in  de  3-5  p  golflengteband.  De  eerste  camera  is  eenvoudig  te  gebruiken,  maar 
heeft  een  kleinere  field-of-view.  De  tweede  camera  beslaat  bijna  45  graden,  wat  in  de 
huidige  opstelling  een  betere  dekking  geeft  van  het  te  bewaken  terrein. 

Infrarood  camera’s  in  de  3-5  p  golllengte  band  zijn  gevoelig  voor  zowel  een  deel  van  de 
(gercflecteerde)  straling  van  de  zon,  als  voor  door  objecten  uitgezonden  warmtestraling. 
Het  temperatuursverschil  van  een  persoon  met  een  niet  door  zonverhitte  achtergrond  is 
daarmee  uitstekend  te  detecteren  op  de  voor  deze  toepassing  relevante  afstanden. 

Ook  mist  heeft  weinig  invloed.  Alleen  zeer  hevige  regenval  of  sneeuw  zal  de  prestaties 
verminderen.  Ook  kunnen  veranderingen  in  de  achtergrond  door  tijdelijke  opwarming 
door  de  zon  (zeker  bij  half  bewolkt  weer)  voor  alarmen  zorgen,  die  echter  lang  op  een 
plaats  blijven  en  na  tracking  eenvoudig  te  elimineren  zijn. 

4.3. 1  Algoritme 

Het  te  detecteren  bewegend  object  wijkt  af  van  het  beeld  van  de  achtergrond.  Als  dus  de 
mogelijke  spreiding  van  contrasten  ten  gevolge  van  normale  veranderingen  bekend  is, 
kan  de  kans  worden  berekend  dat  een  contrast  het  gevolg  is  van  een  object.  Door  een 
drempel  te  leggen  op  een  aan  kans  gerelateerd  contrast,  wordt  daarmee  het  aantal  te 
verwachten  valse  alarmen  constant.  Dit  wordt  (net  als  bij  radar)  constant  false-alarm 
rate  (CFAR)  detectie  genoemd.  Als  de  spreiding  van  contrasten  een  normale  verdeling 
heeft,  kan  de  standaarddeviatie  worden  gebruikt  om  een  CFAR-drempcl  te  bepalen. 

Zo  is  de  kans  dat  het  absolute  contrast,  tengevolge  van  normaal  verdeelde  ruis  of 
beweging,  boven  een  drempel  van  drie  maal  de  standaarddeviatie  uitkomt  in  ons  geval 


TNO-rapport  |  TNO-DV1  2005  A153 


24/32 


0.27%.  Bij  ccn  drcmpcl  van  6  kccr  de  standaard  deviatie  is  dat  al  2*10  7%.  Als  dc 
vcrdcling  nict  normaal  is,  zal  dil  percentage  over  het  algemeen  iets  groter  zijn. 

Dit  is  zeker  het  geval  hi j  bijvoorbeeld  bewegende  takken. 

Een  schatting  voor  de  gemiddelde  achtergrond  en  standaarddeviatie  kan  worden 
verkregen  door  de  statistiek  le  bepalcn  van  alle  waarden  in  een  beeld.  Dit  levert  echter 
een  slechtc  schatting  op  als  het  beeld  niet  egaal  is,  bijvoorbeeld  als  er  zowel  gebouwen, 
ramen,  tegels  en  planten  in  beeld  zijn.  In  dat  geval  kan  de  statistiek  worden  bepaald  van 
waarden  in  een  kleiner  decl  van  het  beeld.  Dit  is  echter  rekenintensief,  geeft  nog  steeds 
problemen  op  overgangen  van  de  ene  soort  achtergrond  naar  de  andere,  en  kan 
bovendien  de  invloed  van  bewegingen  van  bomen  niet  mee  nemen.  Daarvoor  is 
gedraganalyse  in  dc  tijd  nodig.  Vandaar  dat  voor  het  detectiealgoritme  de  statistiek  per 
pixel  wordt  bepaald  uit  meerdere  opeen-volgende  beelden.  Door  middel  van  een 
cyclische  buffer  wordt  een  lopend  gemiddelde,  en  een  lopende  standaarddeviatie 
bepaald,  waarna  per  pixel  detectie  gebeurt  door  de  intensiteit  in  het  huidige  beeld  te 
vergelijken  met  die  van  het  gemiddelde,  en  een  drempel  te  leggen  op  een  in  te  stellen 
aantal  kcren  de  lokale  standaarddeviatie  in  de  tijd. 

Het  algoritme  levert  voor  elk  gedetecteerde  object  een  ‘blob’  (of  cluster)  in  het 
infrarood  beeld.  Dcze  worden  gefilterd  om  ruis-  en  andere  invloeden  te  minimaliseren. 
Van  de  overgebleven  clusters  worden  de  afmeting  en  locatie  in  het  beeld  bepaald, 
evenals  daarvan  afgeleide  relevante  waarden.  De  resultaten  worden  in  het  juiste  formaat 
naar  de  fusie-tracker  (M6T)  gezonden. 

De  output  geschiedt  volgens  het  Universal  Message  Format  dat  is  beschreven  in  Bijlage 
A.  Dc  bij  de  alarmen  bepaalde  kenmerken  zijn  in  eerste  instantie  in  beeldcoordinaten. 
Deze  worden  met  bchulp  van  tijdens  een  ijkprocedure  bepaalde  offsets,  en  de  bekende 
camcraparamcters  (zoals  field-of-view  en  aantal  pixels)  omgerekend  naar  hoeken  in 
wereldcobrdinaten,  te  weten: 

-  Azimuth :  de  horizontale  hoek  van  het  (gewogen)  middelpunt  van  de  detectie, 
ten  opzichte  van  noord  (rechts  is  positief),  in  graden. 

—  Elevatie :  de  verticale  hoek  van  het  (gewogen)  middelpunt  van  de  detectie, 
ten  opzichte  van  horizontaal  (naar  boven  is  positief),  in  graden. 

-  Width :  de  breedte  van  de  bounding  box  rondom  de  detectie,  in  mrad. 

—  Height:  dc  hoogtc  van  de  bounding  box  rondom  de  detectie,  in  mrad. 

—  Max:  het  maximale  binnen  de  detectie  gevonden  contrast  met  de  achtergrond. 

4.4  CSD  module 

De  CSD  is  een  compleet  systeem  bestaande  uit  een  aantal  bewegingssensoren  en 
een  camera.  In  feite  is  de  CSD  de  voorloper  van  het  bewakingsysteem  zoals 
beschreven  in  dit  rapport.  Het  grote  verschil  is  dat  de  CSD  gebruik  maakt  van  een 
enkel  type  sensor,  dat  ook  nog  eens  een  simpel  signaal  afgeeft,  namelijk  een  PIR 
(passive  infrared)  bewegingsmelder.  Het  signaal  is  ‘hoog’  als  er  beweging  wordt 
geconstateerd,  anders  ‘laag’. 

De  bewegingssensoren  worden  op  bekende  plaatsen  in  een  veld  (bijvoorbeeld  rondom 
de  compound)  geplaatst.  De  CSD  demonstreert  vooral  het  nut  van  kleine  en  goedkope 
sensoren  in  een  eigen  netwerkje.  De  bevindingen  van  dit  onderzoek  dat  de  CSD 
beschrijft  met  uitsluitend  de  bewegingsensoren  is  beschreven  in  1 2 J. 
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Een  belangrijk  aspect  van  de  CSD  is  dat  het  gebruik  maakt  van  een  sensometwerk. 

Dat  wil  zeggen  dat  zeer  kleine  en  simpele  sensoren  direct  met  elkaar  communiceren 
kunnen  en  dus  niet  gebruik  hoeven  te  maken  van  een  centrale  computer  om  data  uit  te 
wisselen.  Het  voordeel  van  deze  aanpak  is  veelvoudig  en  worden  in  [2]  uitvoerig 
beschreven.  De  belangrijkste  voordelen  zijn  schaalbaarheid,  stand-alone  operatie  en  de 
snelle  installeerbaarheid  van  dit  systeem. 

De  CSD  toont  een  deel  van  het  systeem  uit  figuur  4. 1 .  Dit  systeem  bestaat  uit  vier 
bewegingsensoren  en  een  centrale  die  ook  een  camera  kan  besturen.  Deze  zijn  op 
gemakkelijk  te  plaatsen  palen  gemonteerd  om  mobiliteit  van  dit  systeem  te 
benadrukken,  zie  figuur  4.5. 

Voor  dit  project  is  de  CSD  is  aangepast  en  maakt  nu  gebruik  van  vier  TNOdes™ 

(TNO  Distributed  Embedded  Systems).  Deze  worden  in  het  project  SOWnet 
beschreven,  een  ander  project  binnen  het  programma  V219. 


Figuur  4.5  (links)  De  bewegingsensor.  Deze  bestaat  uit  een  TNOdes  en  een  bewegingsmelder  als 
onderdeel  van  het  sensometwerk.  (rechts)  De  camera  is  voor  observatiedoeleinden  als 
onderdeel  van  de  CSD. 

De  centrale  verwerkingscomputer  verzorgt  (naast  communicatie  met  de  TNOdes  en  de 
camera)  de  presentatie  van  de  informatie  van  het  systeem  naar  de  gebruiker.  Op  het 
scherm  wordt  het  camerabeeld  en  de  toestanden  van  de  sensoren  getoond.  In  de  CSD 
zijn  er  vier  bewegingsensoren.  Deze  kunnen  vijf  verschillende  toestanden  aannemen, 
namelijk  ‘actief ,  ‘beweging’,  ‘beweging  is  weg’,  ‘sensor  niet  meer  aanwezig’  en 
‘sensor  nog  niet  aanwezig’.  Elke  toestand  wordt  met  een  bepaalde  kleurcombinatie 
gerepresenteerd.  Voor  de  M6T  wordt  in  dit  project  alleen  de  melding  ‘beweging’  als 
contact  doorgegeven  op  het  netwerk. 

Na  een  bewegingsmelding  van  een  sensor  zal  de  (pan/tilt/zoom)  camera  zich  zo 
instellen  dat  de  omgeving  van  de  signalerende  sensor  te  zien  is  op  het  scherm  om 
visueel  poolshoogte  te  kunnen  nemen.  De  camera  zal  altijd  de  sensor  die  als  laatste  een 
melding  geeft  in  beeld  proberen  te  krijgen.  Hiervoor  zijn  de  sensorposities  van  tevoren 
in  het  geheugen  van  de  computer,  die  bij  de  camera  hoort,  opgeslagen.  De  camera  kan 
dus  niet  zelf  posities  van  objecten  detecteren  (zoals  de  radar  en  de  infrarood  camera)  en 
is  als  zodanig  niet  opgenomen  in  de  M6T  om  observaties  van  verschillende  sensoren  tot 
tracks  te  fuseren. 
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5  Fusie  en  Tracking  module  M6T 


Hct  tracking  algoritme  heeft  tot  duel  de  metingen  van  een  of  mccrdcre  sensoren  tc 
associeren  met  bewegende  doelen  in  dc  omgeving.  Dc  basis  hiervoor  wordt  gevormd 
door  een  extended  Kalman  filter  dat  gebruik  maakt  van  meerdere  hypotheses  om 
contacten  (detecties)  met  tracks  te  associeren. 

Op  basis  van  een  serie  contactcn  geassocieerd  met  een  doel  wordt  een  schatting 
berekend  voor  de  werkelijke  beweging  van  hct  doel.  Een  reeks  van  deze 
toestandsschattingen  vormt  een  track.  De  toestandsvariabelen  die  geschat  kunnen 
worden  door  hct  track ing-proces  hangen  af  van  de  beschikbare  sensordata. 

De  bewegingsmelders,  de  infraroodcamera  en  de  radar  geven  allemaal  series  van 
detecties.  De  sensoren  leveren  daarmee  verschillende  parameters  van  de  gedetecteerde 
doelen:  de  radar  geeft  afstand  en  radiale  snclheid,  dc  IR  camera  geeft  azimut  en 
elevatie,  en  de  bcwegingmelders  geven  enkel  de  aanwezigheid  van  een  doel  binnen  het 
meetbereik.  Dit  vormt  de  input  van  hct  tracking  algoritme,  en  deze  associeert  de 
detecties  tot  tracks  van  een  of  meerdere  doelen.  Op  deze  wi  jze  wordt  de 
sensorinformatie  gefuseerd,  en  deze  inkapseling  van  de  datafusie  in  het  tracking- 
algoritme  word  dan  ook  ‘Fuse  while  track’  genoemd. 

De  geometrische  en  dynamische  informatie  gegeven  door  de  detecties  wordt  meestal 
gegeven  in  het  coordinaatsysteem  van  de  sensor  (de  mcetruimte).  De  tracks  zijn 
gegeven  in  een  cartesisch  of  geodetisch  systeem  (toestandsruimte)  dat  geschikt  is  om 
een  sensoronafhankelijk  omgevingsbeeld  op  te  bouwen.  Bij  meerdere  sensoren  zal  de 
toestandsruimte  daarom  verschillen  van  de  afzonderlijke  meetruimtes. 

Een  overzicht  van  het  fusie  en  tracking-proces  is  gegeven  in  figuur  5. 1 .  Op  het  moment 
dat  er  een  detectie  binnenkomt  wordt  op  basis  van  het  ti  jdstip  waarop  de  detectie  plaats 
vond  (timestap)  en  dc  laatst  geschatte  toestand  van  de  track  (track  update)  een 
voorspelling  (prediction)  gedaan  waar  het  object  zich  op  het  ti  jdstip  van  detectie  bevind. 
Deze  voorspelling  wordt  getransformeerd  naar  de  specifieke  meetruimte  van  de  sensor 
waarmee  de  detectie  gemeten  is.  Op  basis  hiervan  vind  associate  van  de  detectie  aan  de 
track  plaats.  Het  verschil  tussen  de  voorspelde  en  de  gemeten  toestand  wordt  vervolgens 
gebruikt  om  met  behulp  van  een  Kalman  filter  een  nieuwe  toestandschatting  te  maken. 
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Figuur  5.1  Overzicht  van  het  tracking-proces  met  contacten  die  afkomstig  zijn  van  versehillende  sensoren. 

Dc  associatie  van  detecties  aan  een  variabcl  aantal  tracks  kan  op  twee  manieren  gedaan 
worden: 

•  ofwel  met  een  nearest-neighbour  algoritme  waarbij  elke  detectie  afzonderlijk 
geassocieerd  met  het  track  dat,  gewogen  met  de  meet-  en  tracknauwkeurigheid,  het 
dichtst  bij  de  detectie  ligt; 

•  of  door  middel  van  Multi  Hypothese  Tracking  (MHT),  hierbij  worden  versehillende 
dctectie-track  associatiehypotheses  (inclusief  loze  en  gemiste  detecties)  met 
bijbehorende  waarschijnlijkheden  bijgehouden. 

In  gevallen  waar  meerdere  doelen  ambigue  metingen  opleveren  die  slechts  opgelost 
kunnen  worden  door  detecties  van  meerdere  sensoren  en  meerdere  ti  jdstippen  te 
combineren,  zal  de  eerste  methode  niet  toereikend  zijn.  De  meerwaarde  van  MHT 
bestaat  uit  het  feit  dat  meerdere  associatiehypotheses  behouden  worden  totdat  op  basis 
van  latere  detecties  een  ondubbelzinnige  associatie  gemaakt  kan  worden.  De  toestand 
van  het  doel  kan  ook  bijgehouden  worden  bij  gemiste  detecties,  zodat  het  doel  gevolgd 
kan  worden  voor  zolang  deze  zich  binnen  het  meetdomein  van  de  sensoren  bevindt. 

De  versehillende  sensoren  leveren  complementaire  metingen  (de  radar  levert  afstand  en 
snelheid,  de  camera  azimut  en  elevatie)  en  detecties  worden  zowel  tegelijkertijd  als 
asynchroon  door  de  sensoren  gegenereerd.  Hierdoor  is  de  MHT  aanpak  beter  geschikt 
om  gebruik  te  maken  van  de  voordelen  van  een  multi-sensor  systeem.  Dit  wordt  deels 
veroorzaakt  doordat  voor  kortere  tijdsintervallen  tussen  versehillende  detecties  de 
associatiemogelijkheden  sterker  gecorreleerd  zijn.  Om  de  waarschijnlijkheden  van  de 
associatiehypotheses  voor  een  nieuwe  detectie  te  berekenen  moet  de  kans  bekend  zijn 
dat  een  doel  door  geen  enkele  sensor  gedetecteerd  is  in  het  interval  tussen  deze  en  de 
voorlaatste  detectie  van  dit  doel.  Nauwkeurige  kennis  van  de  a  priori  detectiekans- 
dichtheden  van  de  sensoren  is  dus  nodig  om  de  kans  op  een  gemiste  detectie  te  kunnen 
berekenen.  De  dichtheid  van  loze  detecties  kan  geschat  worden  uit  metingen  waarbij 
zich  geen  doelen  in  het  meetdomein  bevinden. 
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Hguur  5.2  Grafische  voorstelling  van  de  M6T  sensor  fusie  en  tracking  module. 

5.1  Resultaten 

De  demonstratie-opstelling  bestond  uit  de  CSD  met  vier  bewegingsensoren,  de  radar  en 
de  intrarood  camera.  De  CSD-sensoren  werden  gebruikt  om  de  andere  twee  typen 
sensoren  te  ‘ triggered  dat  er  beweging  waargenomen  was  in  een  bepaald  gebied  op  het 
veld  rond  de  compound.  Daama  stelden  de  infrarood-camera  en  radar  zich  zo  in  dat  ze 
dat  gebied  konden  waarnemen.  Vervolgens  werd  de  informatie  van  die  twee  sensoren 
gecombineerd  tot  tracks  met  behulp  van  de  M6T  fusie  en  tracker  module.  Het  resultaat 
is  getoond  in  figuur  5.2.  Aan  de  linkerkant  van  deze  figuur  staat  de  locatie  van  de 
waargenomen  objecten  (twee  personen  die  in  het  gebied  liepen)  in  x,y  positie- 
coordinaten.  De  positiecoordinaten  werden  over  een  periode  van  22  seconden  berekend, 
gebruik  maken  van  de  waarnemingen  van  de  beide  sensoren.  Rechtsboven  in  deze 
tiguur  staan  de  waarnemingen  van  de  infrarood  camera,  terwijl  rechtsonder  de  metingen 
van  de  radar  weergegeven  zijn. 

Dit  resultaat  toont  de  principewerking  van  de  tracker-module  en  laat  zien  hoe  data  van 
totaal  verschillende  sensoren  gecombineerd  kan  worden  tot  informatie  die  gemakkelijk 
interpreteerbaar  is  door  een  menselijke  gebruiker. 
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Figuur  5.2  Gecombineerde  track  (links)  van  twee  sensoren,  infrarood  (rechtsboven)  en  radar  (rechtsonder). 
Deze  track  is  berekend  door  de  M6T  en  geeft  de  locatie  van  het  waargenomen  object  in  x,y- 
coordinaten. 
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6  Conclusie 


Het  Testbed  is  gereed  voor  gebruik.  Dc  omgeving  kan  gebruikt  worden  voor  het  testen 
cn  evalueren  van  multi-device  systcmen,  bijvoorbeeld  in  het  kader  van  NEC. 

Er  is  aangetoond  dat  data  van  verschillende  sensorcn,  kunnen  worden  samengevoegd  tot 
bruikbare  infoimatie.  Als  dcmonstratiesystcem  is  er  gekozen  voor  het  detecteren  en 
volgen  van  bewegende  mensen  waarbij  metingen  van  verschillende  sensoren  in  het 
volgproces  worden  gecombineerd. 

Doordat  elk  device  gebruik  maakt  van  DeviceML  kunnen  we  elk  apparaat  (device)  op 
cen  ‘hoog’  systeemniveau  op  een  gestandaardiseerde  wijze  omschrijven. 

Het  is  gebleken  dat  deze  wcrkwijze  zeer  geschikt  is  om  de  verschillende  apparaten  op 
gemakkelijke  wijze  met  elkaar  in  verbinding  te  brengen. 

Tijdens  dit  project  is  gebleken  dat  informatie-uitwisseling  tussen  verschillende 
systemen  in  een  genetwerkte  omgeving  geenszins  triviaal  is.  De  uitdaging  zal  blijven 
zitten  in  het  definieren  van  de  juiste  interfaces  die  aan  de  ene  kant  generiek  en  flexibel 
zijn  en  aan  de  andcre  kant  specifiek  en  applicatieafhankelijk  zijn. 
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Universal  Contact  Message  format 


This  appendix  describes  a  universal  contact  message  to  be  used  between  a  plot  extraction 
algorithm  and  a  tracker.  A  universal  contact  message  improves  the  interchangeability  of 
trackers  and  detection  algorithms.  This  contact  message  is  setup  to  be  easily  extended  with 
additional  sensors  and  sensor  parameters.  Additionally  a  file  header  is  specified. 

Message  format 

Each  message  with  contacts  has  the  following  structure: 

<big/little  endian  id>  <sensor  id>  <message  id> 

<headcr  format  id>  enumber  of  contacts>  cheader  parameter  1  >  . . .  cheader  parameter  n> 
ccontact  format  id>  cmeasurement  parameter  1>  ...  <measurement  parameter  n> 

<contact  format  id>  <measurement  parameter  1>  ...  <measuremcnt  parameter  n> 

A  binary  format  for  the  fields  is  chosen  since  this  decreases  the  message  length  compared 
to  an  ASCII  message.  For  user  readability  the  different  fields  are  split  into  different  lines, 
in  the  actual  message  all  fields  are  concatenated.  The  parameters  mentioned  in  the  header 
line  apply  to  all  detections  (for  example  timestamp  or  surrounding  temperature)  whereas 
the  parameters  in  the  contact  lines  only  apply  to  that  contact.  The  number  of  parameters  in 
the  header  line  and  contact  lines  can  be  unlimitedly  extended  to  the  required  number. 

The  fields  are  described  as: 


field 

format 

description 

big/little  endian  identifier 

U41 

always  contains  number  0x12345678 

sensor  id 

U4 

unique  sensor  number  for  specific  measurement  setup 

message  id 

U4 

serial  number  for  blocks  of  contacts  from  one  sensor, 

for  each  sensor  this  number  starts  with  1 

number  of  contacts 

U4 

number  of  contacts  in  message 

header  format  id 

U4 

header  format  number 

contact  format  id 

U4 

contact  format  number 

contact  format  id 

U4 

contact  format  number 

1  Un  means  unsigned  n  bytes  integer 
Fn  means  n  bytes  floating  point  number 
In  means  signed  n  bytes  integer 
Sn  means  n  bytes  string 
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Example 

Two  contacts  from  a  radar  with  sensor  id  1  need  to  be  passed  to  the  tracker. 

Both  contacts  have  the  same  timestamp  of  3.04  s  (F4).  The  first  contact  is  a  cluster  of  12 
detections  and  contains  both  range  of  4.6  m  (F4)  and  velocity  of  3.42  m/s  (F4) 
information.  The  second  contact  only  contains  range  information  of  10.3  m  (F4). 

Since  the  beginning  of  the  measurement  this  is  message  34.  This  is  written  in  the  universal 
contact  message,  using  specifications  mentioned  below,  like: 

12345678  1  34  1  2  3.04  12  1  4.6  3.42  2  10.3 

In  more  readable  form  this  looks  like: 

12345678  1  34 
1  2  3.04  12 

1  4.6  3.42 

2  10.3 

Everybody  that  will  use  this  format  will  have  to  assign  a  sensor  id  to  his  or  her  sensors. 
This  sensor  id  can  differ  for  different  measurement  setups. 

Below  a  sample  specification  is  given. 

Sensor  1 :  2.4  GHz  FMCW  radar 

Header  format  id  1 :  number  of  contacts  in  message  (U4),  timestamp  since  beginning 
measurement  [s J  (F4) 

Contact  format  id  1:  range  [m]  (F4),  velocity  [m/s]  (F4),  Amplitude  (F4),  number  of 
detections  in  contact  (U4) 

Contact  format  id  2:  range  [m]  (F4) 

Sensor  2:  Passive  Radar 

Header  format  id  1 :  number  of  contacts  in  message  (U4),  GPS  timestamp  |F4|  (#seconds 
since  midnight) 

Header  format  id  2:  number  of  contacts  in  message  (U4) 

Contact  format  id  1:  range  [m]  (F4),  doppler  [Hz]  (F4) 

Contact  format  id  2:  range  [m]  (F4),  doppler  [Hz)  (F4),  Azimuth  [°]  (F4),  Amplitude  [aj  (F4) 
Contact  format  id  3:  range  [m]  (F4),  doppler  [Hz]  (F4),  Azimuth  [°]  (F4),  Amplitude  [?] 
(F4),  TrackID  [-]  (U4),  Latitude  (WGS84)  [°]  (F4),  Longitude 
(WGS84)  [°]  (F4),  Altitude  [m]  (F4),  Mode  3/A  [-]  (S4) 

Contact  format  id  4:  time  [s]  (F4),  range  [m]  (F4),  doppler  [Hz]  (F4) 
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